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Abstract 

We  proposed  in  a  recent  article  that  a  product  development  organization  can  be  analyzed 
as  a  system  composed  of  more  or  less  repetitive  processes  of  activities.  Taking  this  process 
view,  we  investigate  in  this  paper  how  to  apply  process  models  to  better  manage  development 
cycle  time.  Through  simulation  experiments,  we  assess  the  potential  impact  of  various  changes 
in  the  operation  of  a  sample  product  development  organization.  From  the  eight  scenarios  that 
we  analyze,  we  are  able  to  draw  some  insights  and  recommendations  for  reducing  project 
completion  times. 
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Statement  of  Contribution 

The  motivation  for  the  research  reported  here  is  the  growing  competitive  importance  of  product 
development  time.  Business  observers  have  argued  that  the  intensification  of  global  competition 
has  created  enormous  pressures  on  firms  to  accelerate  the  process  of  developing  and  launching  new 
products.  We  submit  that  while  product  development  projects  are  often  viewed  as  collections  of 
unique  entities,  in  reality  different  projects  within  a  given  organization  often  exhibit  substantial 
similarity  in  the  overall  flow  of  constituent  activities.  Moreover,  while  most  of  the  planning 
tools  available  to  managers  assume  that  projects  are  independent  clusters  of  activities,  in  reality 
many  organizations  must  manage  concurrent  projects  that  place  competing  demands  on  shared 
human  and  technical  resources.  We  therefore  propose  that  a  process  view  -  that  is,  a  view  of 
the  development  process  as  a  more  or  less  repetitive  "design  production  process"  -  can  provide 
a  framework  for  better  understanding  product  development  time  in  organizations  with  multiple 
concurrent  projects  that  utilize  shared  resources.  In  this  paper,  we  investigate  how  to  apply 
process  models  to  better  manage  development  cycle  time.  Through  simulation  experiments,  we 
assess  the  potential  impact  of  various  changes  in  the  operation  of  a  sample  product  development 
organization.  From  our  analyses,  we  are  able  to  draw  some  insights  and  recommendations  for 
reducing  project  completion  times. 


Many  firms  treat  [cycle  time]  as  immutable,  a  fact  of  life  m  their  industry. 

Hayes,  Wheelwright,  and  Clark  (1988) 


As  noted  by  business  observers  such  as  Blackburn  (1991),  Clark  and  Fujimoto  (1989),  Rosen- 
thal (1992),  Stalk  and  Hout  (1990),  and  Wheelwright  and  Clark  (1992a,  1992b),  the  intensification 
of  global  competition  has  put  enormous  pressures  on  firms  to  accelerate  the  process  of  developing 
and  launching  new  products.  In  Adler  et  al.  (1992a),  we  proposed  that  insights  about  development 
cycle  time  can  be  gained  by  viewing  the  product  development  process  as  a  more  or  less  repetitive 
"design  production  process."  Our  approach  was  premised  on  two  hypotheses  concerning  the  de- 
velopment activities.  First,  we  submit  that  while  product  development  projects  are  often  viewed 
as  collections  of  unique  entities,  in  reality  different  projects  within  a  given  organization  often  ex- 
hibit substantial  similarity  in  the  overall  flow  of  constituent  activities.  Second,  while  most  of  the 
planning  tools  available  to  managers  assume  that  projects  are  independent  clusters  of  activities, 
in  reality  many  organizations  must  manage  concurrent  projects  that  place  competing  demands 
on  shared  human  and  technical  reosurces.  A  process  view,  therefore,  can  provide  a  framework 
for  better  understanding  organizations  that  pursue  multiple  concurrent  non-unique  projects  using 
shared  resources.  In  particular,  this  approach  should  enable  us  to  quantify  the  congestion  effects 
that  arise  from  contention  for  shared  resources  among  concurrent  projects. 

Taking  the  process  view,  we  suggest  modeling  a  product  development  organization  as  a 
"stochastic  processing  network"  in  which  engineering  resources  are  "workstations"  and  projects 
are  "jobs"  that  compete  for  "services"  from  the  workstations  We  characterized  this  class  of 
stochastic  processing  network  models  in  Adler  et  al.  (1992a),  and  we  also  constructed  a  specific 
model  of  a  sample  firm's  product  development  organization.  In  this  paper,  we  use  these  process 
models  to  assess  the  potential  impact  of  various  changes  in  the  product  development  organization 
through  several  simulation  experiments.  From  the  eight  scenarios  that  we  present  here,  we  draw 
several  general  insights  and  recommendations  for  reducing  development  cycle  time. 

The  paper  is  organized  as  follows.  Section  1  discusses  in  more  detail  the  process  model 
approach.  We  present  in  Section  2  the  sample  organization,  which,  to  preserve  its  anonymity,  we 
call  the  Plastics  Division  of  Chemicals,  Inc.  Section  3  describes  the  stochastic  processing  network 
model  that  we  constructed  for  the  Plastics  division.  Using  the  simulation  package  SIMAN  (Pegden 
et  al.  1990),  we  simulated  the  process  model  and  obtained  predictions  of  development  cycle  time 
that  we  compared  with  actual  Plastics  division  performance.  The  results  of  these  simulations, 
which  we  refer  to  as  the  "base  case,"  are  presented  in  this  Section  3. 


Sections  4-7  explore  the  effects  of  reducing  the  total  "load"  on  the  system  through  different 
means.  In  Section  4.  we  show  how  process  models  can  identify  bottlenecks  in  the  system  and  assist 
in  decisions  regarding  resource  augmentation  and  allocation.  Section  5  investigates  the  benefits 
of  compressing  the  amount  of  time  required  to  complete  activities.  The  division  can  also  reduce 
its  load  by  controlling  the  number  of  projects  it  initiates.  The  various  methods  of  input  control 
are  the  subjects  of  Sections  6  and  7. 

In  Section  8  we  present  simulation  experiments  in  which  we  vary  the  amount  of  work  shared 
among  resources.  We  assume  in  all  our  models  that  each  workstation  uses  the  round-robin  service 
discipline,  and  in  Section  9  we  investigate  the  effects  of  switchmg  to  the  first-m-first-out  (FIFO) 
discipline.  The  effects  of  rework  and  prototyping  cycles  are  studied  in  Section  10.  In  Section 
11,  we  demonstrate  the  benefits  of  a  centralized  management  system.  Finally,  we  summarize  our 
findings  in  Section  12. 

1     The  Modeling  Framework:  Stochastic  Processing  Network  Models 

We  demonstrated  in  Adier  et  al.  (1992a)  that  for  an  important  class  of  product  development 
organizations,  namely,  those  that  pursue  multiple  concurrent  non-unique  projects  using  shared 
resources,  one  can  model  the  product  development  function  as  a  "stochastic  processing  network"  in 
which  engineering  resources  are  "workstations "  and  projects  are  "jobs'"  that  compete  for  "service" 
from  the  workstations. 

A  workstation,  or  resource,  is  composed  of  one  or  more  interchangeable  and  identical  servers 
working  in  parallel.  Each  workstation  corresponds  to  a  pool  of  employees,  typically  with  the  same 
title,  who  perform  the  same  functions.  The  servers  are  the  technicians  or  engineers  who  make  up 
the  pool.  The  organization  processes  projects,  or  jobs,  which  consist  of  collections  of  tasks  that 
require  services  from  specified  resources  in  specified  orders  These  precedence  constraints,  which 
we  illustrate  using  PERT-style  diagrams,  allow  some  tasks  to  be  performed  in  parallel  but  require 
others  to  be  performed  sequentially.  When  several  tasks  may  begin  processing  at  the  same  time, 
we  refer  to  the  phenomenon  as  a  "fork";  when  a  task  may  not  begin  until  several  other  tasks  have 
been  completed,  we  call  it  a  "join."  We  think  of  projects  "traveling"  among  the  resources,  forking 
and  joining  as  necessary  into  activities  to  be  processed.  If  a  server  is  available  when  a  project 
arrives  at  a  workstation,  then  the  server  immediately  begins  working  on  the  activity  Otherwise, 
the  project  waits  in  an  in-box,  or  "queue,"  until  a  server  becomes  available. 

The  processing  network  is  stochastic  because  times  between  new  project  starts  (interarrival 
times),  times  required  to  complete  activities  (processing  times),  and  precedence  requirements 
may  all  be  subject  to  statistical  variability    We  say  that  projects  are  of  the  same  "type"  if  their 


individual  precedence  constraints,  processsing  times,  and  interarrival  times  can  be  characterized 
by  the  same  set  of  probability  distributions. 

The  models  we  just  described  appear  to  share  many  characteristics  with  queueing  network 
models  of  manufacturing  systems.  Our  models,  in  fact,  are  generalizations  of  queueing  network 
models.  The  new  feature  introduced  here  is  the  fork  and  join  structure,  which  allows  simultaneous 
processing  of  different  activities.  The  ease  with  which  tasks  fork  is  one  of  the  distishguishing  char- 
acteristics of  the  product  development  environment.  Whereas  manufacturing  activities  typically 
do  not  allow  for  a  component  or  subassembly  to  split  into  different  parallel  processes,  designs  and 
drawings  can  be  duplicated  so  that  several  people  can  work  on  them  simultaneously. 

Stochastic  processing  network  models  offer  several  advangtages  over  PERT  and  CPM  niethods, 
particularly  in  terms  of  predicting  product  development  cycle  time.  PERT  models  depict  an 
idealized  flow  of  project  activites  in  which  activity  times  are  predictable  and  first  attempts  always 
succeed.  Many  product  development  organizations,  on  the  other  hand,  face  uncertainties  in  both 
activity  times  and  number  of  activity  repetitions,  and  our  process  models  naturally  capture  these 
phenomena.  Furthermore,  PERT  and  CPM  analyses  often  assume  that  resources  are  dedicated 
to  a  single  project  at  a  time.  Our  proc<='ss  models,  on  the  other  hand,  explicitly  account  for  the 
congestion  effects  arising  from  contention  for  shared  resources  among  concurrent  projects.  Our 
analysis  in  Adler  ei  al.  shows  that  these  congestion  effects  can  greatly  delay  project  completion. 
Whereas  previous  studies  of  product  development  were  typically  concerned  with  management  of 
individual  projects,  our  approach  focusses  on  the  management  of  resources  as  well 

2     The  Research  Site 

Our  host  for  this  project  was  the  Plastics  division  of  Chemicals  Inc.  (Figure  1  shows  an  organi- 
zation chart  of  Chemicals  Inc.).  The  Plastics  division  made  plastic  parts  and  accounted  for  some 
7%  of  Chemicals'  total  domestic  sales.  Recently,  it  had  lost  several  possible  contracts  to  its  prin- 
ciple competitor,  a  large  Japanese  firm  with  significantly  faster  product  development  Thus  both 
divisional  and  corporate  management  were  interested  in  accelerating  the  product  development 
cycle. 

The  staff  of  the  technical  department  in  the  Plastics  division  consisted  of  engineers  and  tech- 
nicians divided  into  functional  groups  specializing  in  design  and  applications.  A  technical  services 
group  supported  these  engineering  groups  by  helping  to  make  and  test  product  prototypes  In 
addition,  manufacturing  engineers,  product  managers,  salespeople,  and  other  staff  members  all 
made  critical  contributions  to  development  projects.  These  resources  constitute  the  workstations 
in  our  network. 


Project  Types 

The  network  processes  two  types  of  projects,  new  products  and  reformulations.  As  we  explained 
in  Section  2,  projects  of  each  type  are  assigned  either  priority  1  or  priority  2.  During  the  few 
years  prior  to  our  project,  the  Plastics  division  has  shifted  much  of  its  effort  to  developing  new- 
products.  The  manager  of  the  Plastics  division  estimated  that  his  group  initiates  an  average  of 
three  priority  1  new  product  projects  and  2.5  priority  2  new  product  projects  every  year  On  the 
other  hand,  an  average  of  one  reformulation  project  of  each  priority  designation  was  started  every 
year.  These  figures  are  summarized  in  Table  2.  (We  were  told  by  our  informants  that  the  mix  of 
work  can  oscillate  between  new  product  and  reformulation  projects  over  periods  of  several  years, 
so  an  important  feature  of  our  model  is  its  ability  to  reflect  a  changing  mix  of  work  ) 

Activities  and  Precedence  Constraints 

To  identify  the  activities  that  partitioned  a  project,  we  turned  to  a  "phase  system"  recently 
developed  by  the  Plastics  division  to  serve  as  an  internal  guideline  for  new  product  development 
This  system  partitions  the  development  of  a  project  into  four  phases,  each  phase  consisting  of 
a  set  of  issues  to  resolve.  In  Phase  1  ("Concept/Feasibility"),  a  small  team  of  marketing  and 
product  development  people  explore  technical,  manufacturing,  and  marketing  feasibility.  \  full 
team  is  assembled  in  Phase  2  ("Project  Plan/Team")  and  a  project  plan  is  drafted.  Phase 
3  ("Product  Development")  marks  the  project's  peak  effort;  here,  the  team  builds  and  tests 
prototypes,  working  out  technical,  legal,  and  marketing  issues  in  detail.  Manufacturing  ramp-up 
of  the  prototype  takes  place  in  Phase  4  ("Manufacturing  Standardization/Launch").  This  last 
phase  includes  a  concentrated  effort  to  eliminate  any  remaining  technical  wrinkles  and  it  closes 
with  the  project  launch. 

We  chose  to  aggregate  Phases  1,  2,  and  4  into  a  single  activity  each,  and  model  Phase  3  in 
more  detail.  We  focused  on  Phcise  3  because  it  contains  the  bulk  of  project  work;  it  also  proved 
to  be  the  time  of  crispest  activity  description.  Table  3  describes  the  8  activities  involved  in  a  new 
product  development  project.  Because  reformulation  projects  deal  with  existing  products,  they 
often  skip  Phases  1  and  2  entirely  and  marketing  activities  tend  to  be  minimal 

Figures  2  and  3  illustrate  the  precedence  constraints  among  these  activities  for  new  product 
projects  and  reformulation  projects,  respectively.  For  example,  Figure  2  shows  that  new  product 
projects  begin  with  Phase  1  and  move  to  Phase  2  after  Phase  1  has  been  completed.  Once  Phase 
2  is  finished,  engineers  and  technicians  simultaneously  begin  working  on  technical  and  marketing 
issues.  On  the  technical  side,  the  engineers  and  technicians  build  and  test  prototypes;  on  the 
marketing  side,  market  position  is  established,  sales  strategies  formulated,  and  lead-customer(s) 


identified.  Once  a  prototype  meets  specifications  in  the  development  lab,  it  is  sent  to  manufactur- 
ing for  ramp-up.  Prototyping  and  manufacturing  scale-up  are  iterated  until  a  prototype  satisfies 
all  product,  materials,  and  manufacturing  requirements. 

Meanwhile,  once  a  prototype  has  been  built  and  marketing  activities  have  been  completed,  the 
specifications  group  begins  exploring  whether  the  product  is  subject  to  government  regulations. 
The  prototyping,  marketing,  and  specifications  activities  culminate  in  a  final  qualification  testing. 
Finally,  the  project  enters  Phase  4,  where  the  project  undergoes  full  manufacturing  scale-up, 
documentations  are  finalized,  and  the  product  is  launched. 

Our  conversations  with  the  Plastics  division  led  us  to  conclude  that  prototyping  and  manu- 
facturing activities  are  likely  to  require  several  iterations  before  they  are  successfuly  completed, 
and  that  products  are  more  likely  to  fail  at  the  prototyping  stage  than  the  manufacturing  scale-up 
level.  Figure  2  shows  that  75%  of  prototypes  need  to  be  repeated.  In  addition,  manufacturing 
scale-up  results  in  the  building  of  another  prototype  60%  of  the  time  (Thus,  the  average  number 
of  times  the  activities  manufacturing  scale-up  and  prototyping  are  carried  out  are  ( 1  -  60)"'  =  2.5 
and  2.5  ■  (1  —  .75)"'  =  10,  respectively.)  All  other  activities,  however,  are  successful  after  the 
first  attempt.  In  reality,  it  is  possible  for  some  of  these  to  be  repeated  several  times  (for  example, 
a  qualification  test  may  reveal  that  the  prototype  does  not  meet  certain  specifications),  but  we 
include  only  iterations  that  our  host  felt  were  significant  and  most  likely  to  occur 

It  is  worth  noting  that  our  routing  structure  is  "Markovian,"  meaning  that  the  probability 
of  success  of  an  activity  is  entirely  independent  of  history,  and  in  particular  of  the  number  of 
times  that  the  activity  has  been  carried  out.  One  can  imagine  another  situation  in  which,  say,  a 
fifth  prototype  is  likely  to  be  completed  in  less  time  and  with  greater  surety  than  the  preceding 
four.  On  the  other  hand,  four  failed  prototypes  might  signal  a  particularly  difficult  project  in 
which  the  fifth  effort  is  highly  likely  to  be  unsuccessful.  As  our  informants  at  the  Plastics  division 
were  unable  to  characterize  their  prototyping  activities  in  more  detail  than  "average  number  of 
iterations,"  we  settled  for  the  Markovian  routing  structure.  Subsequent  studies  can  explore  this 
issue  in  greater  detail. 

Figure  3  illustrates  the  flow  of  activities  in  reformulation  projects.  Because  reformulation 
projects  constitute  a  very  small  fraction  of  project-related  work,  we  collected  only  summary  data 
and  consequently  we  do  not  model  reformulation  projects  at  the  same  level  of  detail  as  new 
product  projects.  For  example.  Figure  3  shows  no  iterations  between  the  activities,  whereas 
in  reality,  one  typically  experiences  several  iterations  of  the  prototyping  activities.  (Even  with 
these  simphfications,  however,  our  models  were  still  able  to  predict  cycle-time  performance  with 
reasonable  accuracy.) 


Although  the  product  development  group  considered  its  principal  mandate  to  be  the  devel- 
opment of  "new  products,"  it  also  handled  "reformulations'"  —  projects  to  replace  the  materials 
in  existing  products  —  and  it  supported  products  on  the  market.  New  product  development  and 
support  efforts  were  typically  triggered  by  customer  interest;  reformulations  arose  either  when  a 
vendor  discontinued  a  constituent  material  or  when  a  better  material  became  available. 

Management  assigned  formal  priorities  to  projects  to  help  resources  allocate  their  time  Typ- 
ically, projects  involving  the  development  of  new  products  were  given  priority  I  (the  highest 
priority)  whereas  most  reformulation  projects  were  treated  as  priority  2.  Reformulation  projects 
tended  to  have  little  urgency:  the  plant  might  have  several  months'  supply  of  the  current  material. 
and  the  potential  cost  savings  from  using  a  different  material  was  typically  small.  Only  rarely  did 
circumstances  force  reformulation  projects  into  top  priority 

Managers  and  engineers  often  expressed  exasperation  over  the  long  delays  that  priority  2 
projects  suffered  while  waiting  for  attention  from  product  managers  or  the  manufacturing  plant. 
If  the  priority  reflected  the  true  business  importance  of  the  project,  then  such  delays  might  seem 
inevitable  and  even  appropriate.  Nevertheless,  one  project  we  studied  had  spread  two  person- 
months  of  work  over  2.5  years,  raising  questions  about  inefficiencies  due  to  mental  set-up  time,  the 
opportunity  cost  of  delay  in  getting  the  product  to  market,  and  the  toll  of  prolonged  management 
distraction.  One  goal  of  this  paper  is  to  quantify  the  delays  arising  from  various  management 
policies  so  that  these  costs  can  be  evaluated  more  explicitly. 

3     The  Simulation  Model 

Resources 

The  processing  network  model  consists  of  seven  workstations,  corresponding  to  the  seven  resource 
pools  Product  Development  (PD)  Engineers,  Product  Development  (PD)  Technicians,  Manufac- 
turing Engineers,  Application  Engineers,  Technical  Services,  Product  Management,  and  Specifi- 
cations. Table  1  lists  the  engineering  resource  pools,  the  number  of  engineers  or  technicians  in 
each  pool,  and  the  maximum  work  capacity  of  each  group  Management  estimates  of  average 
work  week  for  these  resources  vary  between  40  and  55  hours  per  week,  and  we  allocate  additional 
capacity  to  resource  pools  that  belong  in  the  technical  department  of  the  Plastics  Division  (these 
are  PD  engineers  and  technicians,  application  engineers,  and  technical  services)  These  resources 
typically  work  extra  hours  when  projects  are  backlogged  or  when  deadlines  approach,  and  the 
maximum  server  capacities  shown  in  Table  1  reflect  the  maximum  number  of  hours  that  these 
resources  work  during  critical  periods. 


Processing  and  Interarrival  Times 

The  amount  of  time  that  resources  devote  to  each  activity  is  displayed  in  Tables  4  and  5.  Each 
activity/resource  cell  in  Table  4  shows  the  average  number  of  hours  that  the  resource  spends  on 
that  activity  per  iteration.  An  empty  cell  indicates  that  the  resource  does  not  contribute  to  that 
activity. 

Table  5,  on  the  other  hand,  shows  the  fraction  of  time  that  resources  spend  on  administrative 
and  support  activities.  The  amount  of  time  spent  on  support  reflects  the  nature  and  role  of  the 
resource  pool.  For  example,  because  the  primary  responsibility  of  manufacturing  engineers  is  to 
the  manufacturing  operation,  they  spend  the  bulk  of  their  time  on  activities  outside  the  product 
development  arena.  Hence  the  fraction  of  time  they  spend  on  support  activities  is  relatively  high 

We  model  all  interarrival  times  and  processing  tmies  as  exponentially  distributed.  (The  only 
exception  is  the  interarrival  times  of  administrative  duties,  which  we  take  to  be  deterministic  ) 
Other  distributional  forms  (e.g.,  Beta,  Gamma,  Normal)  are  clearly  possible,  but  we  did  not  have 
sufficient  data  to  justify  other  choices  of  distributions  Moreover,  our  preliminary  experiments 
indicated  that  cycle  times  are  not  significantly  affected  by  the  distributions  that  we  used  —  we 
conjecture  that  since  there  are  many  contributing  factors  to  the  total  level  of  uncertainty  in  the 
network,  a  small  change  in  the  variability  of  processing  times  would  not  have  much  impact  on 
overall  performance. 

Pooling 

We  also  include  a  feature  that  allows  resource  groups  to  share  their  work,  in  particular,  for 
overutilized  groups  to  reallocate  their  work  to  those  that  are  less  heavily  loaded.  We  learned  from 
discussions  with  the  Plastics  division  that  product  development  engineers  often  reassign  part  of 
their  work  to  the  product  development  technicians  during  critical  periods  In  our  simulation 
model,  we  let  product  development  engineers  reassign  work  to  product  development  technicians 
whenever  there  are  more  than  five  ongoing  projects.  We  assume  that  work  can  be  transferred  from 
PD  Engineers  to  PD  Technicians  only  in  Phase  1,  Prototyping,  and  Manufacturing  Scale-f  -^  For 
each  of  these  activities,  at  most  30%  of  the  engineers'  work  can  be  given  to  technicians. 

Service  Discipline 

The  last  component  in  the  simulation  model  that  we  need  to  specify  is  the  service  discipline  —  the 
rule  by  which  an  engineer  or  technician  chooses  her  next  task  from  the  in-box.  We  implement  the 
"base  case"  using  the  "round-robin"  service  discipline  at  each  workstation  with  service  periods 
equalto  two  weeks.  Under  this  discipline,  a  free  engineer  or  technician  takes  the  first  top  priority 


task  in  her  queue  and  works  on  it  for  two  weeks  or  until  the  task  is  finished  If  she  completes 
the  task  within  two  weeks,  the  corresponding  job  moves  on  to  its  successor  task(s),  forking  and 
joining  as  necessary.  Otherwise,  the  task  returns  to  the  end  of  the  queue,  its  remaining  processing 
time  is  updated  to  reflect  the  last  round  of  service,  and  it  waits  until  its  next  access  to  the 
server.  When  the  queue  is  empty  of  top  priority  work,  the  station  serves  the  second  priority 
tasks  in  the  same  manner.  Clearly  there  are  other  possible  choices  for  service  discipline,  including 
first-in-first-out,  last-in-first-out,  or  project  with  the  earliest  due-date  first.  We  conjecture  that 
the  round-robin  service  discipline  is  a  reasonable  approximation  of  human  response  to  important 
competing  demands. 

Percentage  Utilizations 

The  data  we  described  above  is  summarized  in  Table  6,  which  displays  the  "load"  imposed  on 
each  resource  pool  (this  exhibit  assumes  engineers  and  technicians  do  not  pool  their  work).  Each 
cell  in  Table  6  reflects  the  fraction  of  a  resouce  pool's  time  that  is  spent  on  an  activity  For 
example,  the  first  column  shows  that  PD  engineers  spend  40%  of  their  time  on  priority  1  new 
product  projects,  3%  of  their  time  on  priority  1  reformulation  projects,  and  20%  of  their  time  on 
administrative  activities.  The  first  two  rows  of  Table  6  show  that  priority  1  reformulation  work 
requires  much  less  time  from  the  Plastics  division  than  priority  1  new  product  work.  In  addition, 
the  fifth  row  indicates  that  the  bulk  of  the  Plastics  division's  time  is  spent  on  priority  1  work 

The  last  row  shows  the  total  fraction  of  a  resource's  time  that  we  have  accounted  for  (recall 
that  we  give  some  resources  additional  capacity  to  allow  for  over-time  work,  so  we  do  not  expect 
that  the  total  figures  are  100%).  The  numbers  in  this  row  suggest  that  too  much  work  has  been 
allocated  to  product  development  engineers.  As  we  will  show  in  Section  8,  the  possibility  for 
engineers  to  reallocate  part  of  their  work  to  technicians  greatly  improves  development  cycle  time. 

Simulation  Results:  The  Base  Case 

We  present  the  simulation  results  of  the  "base  case"  in  this  section.  The  performance  measure  of 
primary  interest  here  is  project  completion  time,  which  we  will  also  refer  to  as  development  cycle 
time.  It  is  the  amount  of  elapsed  time  from  the  ""beginning"  of  the  project  until  the  "end"  of  the 
project.  New  product  projects  begin  with  concept  generation  and  feasibility  studies  (Pha.se  1), 
and  they  end  with  the  product  launch  (Phase  4).  Reformulation  projects  begin  with  prototyping 
activities  and  end  when  the  product  is  launched  (Phase  4).  Another  measure  of  performance  that 
we  will  report  is  the  number  of  unfinished  prG,ects  in  the  organization. 

To  calibrate  our  models,  we  compare  our  findings  with  figures  provided  by  the  Plastics  division. 


Our  host  was  able  to  provide  us  with  detailed  timelines  for  priority  1  new  product  projects  from 
which  we  were  able  to  compute  average  project  completion  tmies.  Such  records  were  not  available 
for  other  types  of  projects,  and  for  these  statistics,  we  relied  on  estimates  by  the  manager  of  the 
Plastics  division. 

Table  7  shows  that  the  simulated  average  completion  time  of  priority  1  new  product  projects 
is  84  weeks,  compared  to  the  figure  of  82  weeks  reported  by  the  Plastics  division  On  the  other 
hand,  both  simulated  and  reported  figures  indicate  that  the  Plastics  division  requires  more  than 
three  years  to  rinish  priority  2  new  product  projects. 

For  reformulation  projects,  the  simulated  completion  times  are  5  months  for  priority  1  projects 
and  1  year  for  priority  2  projects.  These  numbers  are  somewhat  lower  than  the  figures  estimated 
by  r,  !  manager  of  the  Plastics  division:  6-9  months  for  priority  1  reformulation  projects  and  1-3 
years  for  priority  2  reformulation  projects.  Although  reformulation  projects  are  formally  assigned 
either  priority  1  or  2,  in  reality  they  are  generally  treated  with  less  urgency  than  new  product 
projects  of  the  same  priority.  We  mentioned  in  Section  2  that  reformulation  projects  are  treated 
as  low  priority  work,  and  only  when  a  project  needs  to  be  expedited  is  it  elevated  to  priority  1. 
Consequently,  it  is  likely  that  a  priority  2  reformulation  project  is  often  treated  as  "priority  3." 
This  informal  setting  of  priorities  may  partly  explain  the  biases  in  our  simulation  results:  the 
simulated  completion  time  for  priority  2  reformulation  projects  is  shorter  than  the  actual  project 
cycle  time,  whereas  priority  2  new  product  projects  take  longer  to  complete  than  reported  by  the 
Plastics  division. 

Figures  4-7  show  histograms  and  cumulative  distributions  of  the  project  cycle  time  for  the  2 
types  of  projects.  (Note  that  histograms  quickly  communicate  the  general  characteristics  of  the 
distribution  -  e.g.  skewness  of  the  distribution,  tail  behavior  -  whereas  cumulative  distributions 
are  useful  for  obtaining  percentile  information.)  The  90th  percentiles  of  project  completion  time, 
which  can  be  read  from  Figures  5  and  7,  are  significantly  longer  than  the  corresponding  averages; 
for  example,  while  priority  1  new  product  projects  are  completed  in  84  weeks  on  average.  10%  of 
them  take  more  than  2.5  years!  It  is  clear  with  these  displays  that  it  is  not  enough  to  measure  just 
average  project  completion  times;  information  concerning  the  distribution  of  project  completion 
time  must  also  be  considered. 

To  measure  the  impact  of  variability  and  congestion  on  cycle  time  performance,  the  last 
column  of  Table  7  shows  the  ratio  of  the  actual  average  project  completion  time  (which  appears 
in  the  4'^  column)  to  the  project  cycle  time  predicted  by  PERT  (5'^  column).  This  number,  the 
"actual- to- PERT"  ratio,  compares  the  amount  of  time  that  a  project  spends  waiting  for  resources 
to  the  amount  of  time  it  actually  spends  being  processed.  For  example,  Table  7  indicates  that 
an  average  priority  1  new  product  project  suffers  relatively  little  from  congestion,  as  less  than 


10%  of  its  time  is  spent  idle  waiting  for  resources.  A  priority  2  new  product  project,  on  the 
other  hand,  spends  (on  average)  more  than  half  of  its  time  waiting  to  be  processed.  Priority  2 
reformulation  projects,  which  are  less  time-intensive  than  new  product  projects,  suffer  even  more 
from  the  congestion.  It  spends  approximately  twice  as  much  time  waiting  for  a  resource  as  it  does 
being  processed. 

The  last  four  rows  in  Table  7  compare  the  simulated  number  of  unfinished  projects  in  the 
Plastics  division  with  the  figures  estimated  by  its  manager.  Again,  readers  should  note  the  dis- 
parity between  averages  and  90th  percentiles. 

Finally,  Table  8  shows  the  fraction  of  time  that  each  resource  pool  in  the  core  technical  group 
must  work  its  majcimum  overtime.  These  numbers  appear  to  be  quite  high  for  some  resources  - 
PD  engineers  work  60-hour  weeks  more  than  65%  of  the  time.  On  the  other  hand,  PD  technicians 
work  their  maximum  work-week  less  than  6  weeks  per  year.  Because  much  of  our  data  was 
estimated  by  engineers,  we  suspect  that  they  may  have  over-estimated  their  contribution  and 
under-estimated  that  of  their  technicians.  In  Section  8,  we  investigate  the  benefits  of  sharing 
more  work  between  PD  engineers  and  PD  technicians. 

The  numbers  that  we  report  here  are  "long-run  average"  statistics.  We  obtained  these  figures 
by  simulating  the  models  until  they  reach  "steady-state"  and  taking  the  long-run  averages  as  our 
performance  measures.  The  time  horizon  we  used  in  the  simulation  experiments  -  approximately 
2000  years!  -  is  clearly  inappropriate  when  considering  the  product  development  environment. 
(Each  simulation  run  takes  approximately  80  minutes  of  CPU  time  on  a  Micro  VAX  3800  )  The 
difficulty  here  is  essentially  one  of  finding  the  correct  initial  conditions  for  the  system  If  we  were 
able  to  collect  data  concerning  the  present  distribution  of  workloads  -  i.e.,  the  number  of  projects 
currently  in  the  system  and  the  amount  of  work  remaining  to  be  done  on  each  project  by  each 
resource  -  then  simulation  could  answer  practical  questions  such  as  "how  will  the  system  perform 
over  the  next  five  years."  Because  we  have  no  information  regarding  initial  conditions,  we  must 
simulate  the  systems  long  enough  for  them  to  accumulate  a  reasonable  amount  of  work,  and  we 
approximate  the  performance  measures  by  their  steady-state  values. 

4     Adding  Resources:  Where  are  the  Bottlenecks? 

How  much  would  project  completion  time  be  reduced  if  one  engineer/technician  were  added  to 
a  resource  pool?  Where  would  this  additional  employee  have  the  most  impact''  Stated  another 
way,  which  resource(s)  is  the  bottieneck(s)  in  the  system?  Simulation  can  provide  msiglits  to 
such  questions  by  comparing  scenarios  in  which  different  resource  pools  are  augmented.  Table 
9  displays  average  project  completion  times  under  four  such  scenarios     In  Cases   1,  2.  and  3. 
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one  employee  is  added  to  applications  engineers,  technical  services,  and  product  development 
engineers  respectively.  In  Case  4,  one  additional  person  is  added  to  each  of  these  resource  pools. 
Adding  one  person  amounts  to  roughly  a  3%  increase  in  the  total  resource  pool;  adding  three 
people  amounts  to  about  9%. 

Table  6  indicates  that  product  development  engineers  are  most  heavily  utilized  among  the 
three  groups  being  considered,  so  we  expect  from  queueing  principles  (Kleinrock  1975)  thai  they 
will  be  the  best  resource  to  augment.  Our  simulation  experiments,  whose  results  are  summarized 
in  Table  9,  bear  out  this  expectation.  Moreover,  Table  9  shows  that  adding  a  resource  to  an 
"uncritical"  resource  pool  may  have  virtually  no  impact  on  cycle-time  performance,  as  in  Cases 
1  and  2.  (The  small  increase  in  project  completion  time  under  Case  1  should  be  interpreted 
as  simulation  "noise"  rather  than  a  significant  change  m  cycle  time.)  On  the  other  hand,  the 
results  in  Case  3  indicate  that  additional  investment  in  resources  can  yield  proportionally  much 
larger  reduction  in  cycle-time  if  the  resource  pool  is  chosen  judiciously  Figures  8-9  display  the 
histogram  for  new  product  completion  times  under  Case  3.  Finally,  Case  4  implies  that  not  much 
can  be  gained  over  Case  3  by  adding  an  additional  resource  to  each  of  the  pools  applications 
engineers,  technical  services,  and  PD  engineers. 

A  final  resource  allocation  decision  (that  is,  whether  and  whom  to  hire)  would  require  addi- 
tional economic  analysis  comparing  the  cost  of  an  additional  employee  to  the  savings  resulting 
from  shorter  development  cycle  times.  The  data  we  present  in  these  simulation  studies  could  serve 
as  the  (otherwise  elusive)  foundation  of  such  an  economic  analysis. 

5     Process  Improvement:  Reducing  Processing  Times 

A  second  avenue  for  cutting  cycle  time  is  to  reduce  individual  activity  times  It  is  not  clear, 
however,  how  much  improvement  to  expect.  For  example,  how  far  will  expected  project  completion 
times  drop  if  processing  times  are  reduced  by  5%''  Will  it  be  more  or  less  than  5%? 

Figures  10-11  show  the  histogram  for  new  product  completion  times  when  all  processing  times 
are  reduced  by  5%.  For  both  priority  1  and  priority  2  projects,  the  resulting  decrease  in  average 
cycle  time  is  more  than  5%.  The  average  priority  1  new  product  cycle  time  is  reduced  by  10% 
and  priority  2  by  31%  In  addition,  the  distributions  of  these  times  are  tightened  significantly. 
The  90'  percentile  for  priority  2  new  product  projects,  for  example,  is  reduced  from  350  weeks 
to  220  weeks,  an  improvement  of  37%. 

The  magnitude  of  these  improvements  is  not  surprising  in  light  of  the  high  percentage  utiliza- 
tion of  the  resource  pools  (all  are  approximately  90%).  Recall  from  queueing  principles  that  the 
relationship  between  cycle  time  and  utilization  factors  is  steep  and  nonlinear  when  percentage 
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utilizations  approach  100%.  A  small  decrease  in  processing  times  is  equivalent  to  a  proportional 
decrease  in  utilizations,  so  it  results  in  more  than  proportionally  lower  completion  times.  When 
resources  are  not  heavily  utilized,  the  improvements  will  be  of  only  the  same  magnitude  as  the 
processing  time  reduction. 

We  have  described  in  this  section  a  scenario  in  which  the  product  development  organization 
reduces  the  processing  time  of  all  activities.  One  might  also  ask  if  the  organization  were  to  focus  on 
one  activity  c;  a  subset  of  activities  for  process  improvement,  which  activities  should  management 
target  in  order  to  most  effectively  reduce  project  completion  time.  We  can  easily  modify  our 
simulation  models  to  explore  questions  of  this  type,  and  management  can  use  the  results  of  such 
simulation  experiments  to  help  them  make  decisions  regarding  process  improvement  efforts. 

6     Benefits  of  Controlling  Input 

Durmg  our  time  at  the  Plastics  division,  the  organization  was  involved  in  an  effort  to  improve 
its  procedure  for  selecting  new  projects  according  to  their  likelihood  of  success.  This  effort  was 
prompted  by  management's  concern  about  lengthening  project  cycle  times  and  the  large  number 
of  aborted  projects  that  fruitlessly  tied  up  valuable  resources.  We  can  use  our  simulation  model  to 
assess  the  impact  of  a  simplified  version  of  such  an  "input  control"  policy  in  which  the  organization 
does  not  bid  for  new  projects  when  the  level  of  unfinished  projects  rises  above  a  pre-set  cutoff 
level. 

Because  reformulation  projects  support  established  product  lines,  we  guessed  that  the  orga- 
nization could  not  decline  these  projects  without  great  cost.  Figure  12  shows  the  average  and 
90th  percentile  of  priority  1  new  product  completion  times  for  cutoff  levels  ranging  from  2.5  to  5 
projects,  and  Figure  13  displays  the  same  information  for  priority  2  new  product  projects  Our 
simulation  results  show  that  while  priority  1  project  completion  time  is  not  reduced  by  much, 
priority  2  projects  benefit  greatly  from  this  control  policy.  This  should  not  be  surprising  because, 
as  we  noted  in  Section  10,  priority  1  projects  do  not  experience  much  congestion  whereas  priority 
2  projects  suffer  long  delays  while  waiting  for  priority  1  work  System  improvements  have  much 
greater  impact  on  low  priority  projects  than  on  projects  that  are  given  first  priority. 

The  improvement  in  project  completion  times  must  be  traded  off  against  the  number  of 
projects  lost  as  a  result  of  the  input  control  policy.  Figure  14  shows  the  long-run  average  fraction 
of  projects  that  are  rejected  at  each  cutoff  level.  With  a  cutoff  level  of  20  projects,  an  average 
of  4%  of  potential  new  product  projects  are  lost,  and  average  completion  time  for  priority  2  new- 
product  projects  is  reduced  by  approximately  18%.  The  benefits  of  input  control  policies  would 
obviously  be  considerably  enhanced  if  management  can  further  select  projects  according  to  their 
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probabilities  of  success. 

The  simple  control  policy  we  described  reduces  cycle  time  for  the  obvious  reason  that  it 
decreases  the  amount  of  work  in  the  system.  It  also  has  the  more  subtle  yet  more  powerful  effect 
of  reducing  the  variability  in  the  system  by  restricting  the  total  number  of  jobs  allowed  in  the 
network  at  a  time.  (In  the  base  case,  the  product  development  organization  can  have  more  than 
20  unfinished  new  product  projects  10%  of  the  time,  and  the  number  of  open  projects  can  reach 
40.)  The  improvement  in  cycle  time  with  input  control  is  thus  more  dramatic  that  due  to  a 
proportional  reduction  in  the  rate  of  new  project  starts.  In  Figure  15,  we  present  histograms  of 
project  completion  times  to  illustrate  that  not  only  does  input  control  reduce  the  average  cycle 
time,  it  also  has  a  secondary  effect  of  reducing  the  spread  of  the  distribution. 

7     Operating  as  a  "Pull"  System 

Consider  a  scenario  in  which  the  number  of  concurrent  projects  in  the  organization  is  kept  at  a 
constant  level:  the  development  organization  initiates  a  project  only  when  another  project  has 
been  completed.  This  "pull"  policy,  in  which  project  completions  trigger  project  starts,  can  be 
contrasted  to  a  "push"  policy,  in  which  jobs  are  injected  into  the  sytem  whenever  they  arrive. 
In  order  to  implement  the  pull  system,  the  product  development  organization  must  always  have 
projects  "on  the  shelf"  waiting  to  be  processed.  The  manager  of  the  Plastics  division  confirmed 
that  such  a  scenario  was  indeed  compatible  with  the  experience  of  his  organization  In  this  section 
we  present  simulation  results  for  the  case  in  which  the  number  of  priority  1  new  product  projects 
is  maintained  at  a  constant  level. 

Table  10  compares  the  performances  of  the  push  system  and  the  pull  system  at  varying  levels 
of  concurrent  projects.  The  second  and  third  columns  of  Table  10  show  the  average  completion 
time  for  new  product  projects,  and  the  fourth  and  fifth  columns  display  the  corresponding  figures 
for  reformulation  projects.  The  last  column  shows  the  resulting  priority  1  new  product  throughput 
rate:  the  number  of  priority  1  new  product  projects  completed  per  year.  We  see  immediately  the 
possibility  for  trade-off;  the  more  projects  that  resources  must  handle  concurrently,  the  more 
projects  they  can  complete  each  year.  On  the  other  hand,  the  more  projects  they  must  juggle  at 
the  same  time,  the  longer  it  takes  to  complete  each  individual  project. 

Table  10  shows  that  with  five  concurrent  priority  1  new  product  projects,  the  pull  system 
delivers  better  cycle-time  performance  for  all  project  types,  and  the  average  prionfv  2  new  product 
projects  are  completed  14%  faster.  Moreover,  the  pull  system  produces  at  least  as  many  projects 
as  the  the  base  case  (throughput  rate  is  3.1  projects  per  year). 

We  also  compare  the  pull  system  with  a  push  system  that  is  subject  to  input  control.  Figure 
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16  displays  cumulative  distributions  of  priority  2  new  product  completion  times  for  three  systems 
that  have  approximately  the  same  throughput  rate:  (i)  the  push  system  (ii)  the  push  system  with 
input  control,  where  the  maximum  number  of  concurrent  projects  is  set  to  be  25.  and  (iii)  the 
pull  system  with  the  number  of  concurrent  projects  equal  to  five.  In  each  of  these  three  cases,  the 
throughput  rate  for  priority  1  new  product  projects  is  approximately  three  projects  per  year,  but 
the  pull  system  has  slightly  higher  throughput  rate.  Even  with  the  higher  throughput  rate,  the 
pull  system  performs  better  than  the  other  two  systems;  note  that  the  90'  percentile  is  reduced 
to  270  weeks,  an  improvement  of  23%  over  the  push  system  and  7%  over  the  push  system  with 
input  control. 

The  pull  system  improves  cycle  time  performance  by  eliminating  the  variability  due  to  (un- 
controlled) arrivals  of  new  projects.  It  is  more  effective  than  simple  input  control  as  described 
in  the  previous  section  (in  which  the  system  is  still  essentially  open)  because  it  further  reduces 
variability.  Clearly,  even  greater  benefits  can  be  achieved  by  keepmg  constant  the  number  of 
projects  in  each  category. 

8     Tradeoffs  of  Cross-Training:  Effects  of  Pooling 

Because  product  development  engineers  are  much  more  heavily  utilized  than  product  development 
technicians  (see  Tables  6  and  8),  we  examined  the  consequences  of  sharing  more  work  between 
these  pools.  As  we  noted  in  Section  3,  engineers  and  technicians  in  the  Plastics  division  frequently 
reallocate  their  work  assignments.  In  the  simulation  experiments  described  here,  we  assume  that 
engineers  reassign  a  portion  of  their  work  to  technicians  whenever  the  number  of  ongoing  projects 
exceeds  5.  In  Section  10,  we  assumed  that  30%  of  the  engineers'  work  could  be  performed  by 
technicians.  Here  we  explore  the  effect  of  varying  this  amount  of  transferable  work  The  results 
provide  one  measure  of  the  benefits  of  cross  training. 

Figure  17  shows  the  average  completion  times  for  new  product  projects  with  pooling  levels 
ranging  from  10%  to  70%.  The  numbers  in  parentheses  are  percentage  reductions  in  cycle  time 
resulting  from  giving  an  additional  10%  to  the  amount  of  work  that  PD  engineers  can  reassign 
to  their  technicians.  For  example,  by  increasing  the  fraction  of  pooled  work  from  20%  to  30%, 
average  priority  2  completion  time  is  reduced  by  13%.  (Again,  note  that  the  impact  on  priority  1 
cycle  time  is  negligible.)  The  graph  in  Figure  17  suggests  that  the  expected  benefit  of  additional 
pooling  becomes  less  pronounced  as  the  amount  of  shared  work  increases.  Figure  18  clarifies  this 
statement  further:  As  engineers  reassign  more  work  to  technicians,  the  engineers  gam  slack  time 
while  the  technicians  become  busier.  Eventually  product  development  engineers  cease  to  be  the 
bottleneck. 
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We  make  the  simplifying  assumption  that  no  loss  of  efficiency  results  from  pooling  In  general, 
transfering  work  from  engineers  to  technicians  could  result  in  differences  in  processing  times  or 
in  likelihoods  of  errors.  We  might  expect  higher  levels  of  pooling  to  be  accompanied  by  longer 
processing  times  and  increased  number  of  iterations.  Although  our  hosts  shared  this  expectation, 
they  were  not  able  to  quantitatively  estimate  these  effects  for  us.  Nevertheless,  combining  this 
observation  with  the  insight  gained  from  Figure  17,  it  should  be  clear  that  there  is  an  "optimal" 
level  of  pooling  beyond  which  cycle  time  gets  longer. 

9     Finish  What  You  Started:  The  FIFO  DiscipHne 

We  have  assumed  so  far  that  resources  process  their  tasks  in  a  round  robin  fashion  We  chose  this 
convention  because  it  seemed  to  be  a  reasonable  way  that  workers  might  respond  to  competing 
demands.  An  alternative  service  discipline  is  "first-in-first-out"  (FIFO),  in  which  resources  process 
tasks  in  order  of  arrival,  working  on  each  one  continuously  until  it  is  finished. 

Table  11  displays  cycle  time  performance  under  the  FIFO  service  discipline  Notice  that  it 
shows  no  significant  difference  between  the  round-robin  discipline  and  FIFO  service  in  terms  of 
cycle  time  performance.  We  conjecture  that  this  result  reflects  the  service  period  of  two  weeks 
used  in  the  round-robin  scenario:  if  this  interval  were  cut  to  two  days  or  two  hours,  for  example. 
the  results  might  be  very  different.  We  plan  to  explore  this  topic  further  in  future  research 

The  round-robin  service  discipline  may  not  be  efficient  for  the  reason  that  an  engineer  or 
technician  may  require  some  "mental  set-up  time"  to  relocate  documentation  or  to  recall  relevant 
issues  each  time  she  returns  to  a  project.  In  the  round-robin  service  discipline,  where  resources 
switch  among  projects  frequently,  a  significant  amount  of  time  may  be  spent  in  getting  ready  for 
the  next  task.  We  have  assumed  that  resources  require  no  set-up  time  when  they  begin  a  new 
task,  so  this  set-up  cost  would  be  absent  under  FIFO.  We  investigate  the  effects  of  set-up  time  in 
the  next  section. 

10     Effects  of  Iterating 

To  better  understand  the  effects  of  iterations  between  activities,  we  investigated  several  models 
with  varying  number  of  iterations,  but  with  constant  total  activity  times.  Suppose  that  activity 
A  requires  i  person-weeks  to  be  successfully  completed,  and  p  is  the  probability  that  any  given 
iteration  is  successful  (i.e.,  the  average  number  of  times  that  activity  .4  is  repeated  is  n  =  1/p) 
We  set  the  time  required  to  complete  each  sub-task  (i.e.,  each  iteration)  to  j  =  p  ■  i.  This  allows 
us  to  isolate  the  effects  of  increased  variability  on  total  project  completion  time. 
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We  conducted  two  sets  of  experiments  with  two  different  levels  of  iterations.  In  the  first  set 
of  experiments,  only  prototyping  is  repeated.  In  the  second  set.  prototyping  activities  are  always 
successful  in  the  first  iteration,  but  cycling  back  to  prototyping  can  occur  after  manufacturing 
scale-up.  In  both  sets,  the  probability  of  returning  to  protoyping  ranges  from  0  00  to  0  90  In  a 
third  set  of  experiments,  we  investigated  models  in  which  only  the  prototypmg  activity  is  repeated, 
but  with  FIFO  service  discipline. 

Figures  19-22  summarize  the  results  of  these  experiments.  The  graphs  suggest  that  cycling 
doe  not  significantly  affect  project  completion  time.  For  new  product  projects,  a  marked  increase 
in  project  completion  times  appears  only  when  the  probability  of  repeating  is  very  high  (090). 
The  effects  of  FIFO  service,  on  the  other  hand,  are  rather  interesting.  Under  FIFO,  new  product 
projects  have  uniformly  better  cycle  time  performance  than  under  round-robin,  and  reformulations 
do  uniformly  worse.  This  phenomenon  springs  from  the  fact  that  reformulation  projects  are  much 
smaller  than  new  product  projects.  Under  round-robin  service,  jobs  rotate  in  and  out  of  service 
frequently  with  the  length  of  service  constrained  by  the  predetermined  service  "slice  "  Under  FIFO 
service,  however,  an  activity  can  start  only  when  all  predecessor  activities  have  been  completed, 
so  reformulation  projects  suffer  increased  delay  due  to  the  more  time-consuming  new  product 
projects. 

Our  second  set  of  experiments  incorporates  the  observation  that  total  activity  time  may  not 
be  perfectly  divisible  into  times  for  subtasks.  For  example,  each  iteration  may  involve  some  level 
of  inefficiency  and  consequently  increase  total  activity  times.  In  a  heavily  loaded  system  such  as 
the  one  we  consider,  a  small  increase  in  utilization  levels  can  have  disastrous  effects  on  system 
performance.  We  simulate  this  effect  by  charging  each  activity  with  a  small  set-up  each  time  it  is 
repeated.  As  stated  previously,  this  set-up  can  represent  time  spent  relocating  documentation  on 
the  project,  communicating  with  groups  that  worked  on  the  upstream  task,  or  simply  recalling 
the  project's  relevant  issues.  In  our  experiment,  we  set  the  probability  of  repeating  prototyping 
to  be  090,  and  the  probability  of  returning  to  prototyping  from  manufacturing  scale-up  to  be 
0.80.  (Thus,  the  total  number  of  times  that  prototyping  and  manufacturing  scale-up  are  carried 
out  are  50  and  5  respectively.)  The  set-up  time  accompanying  each  repetition  is  1/2  hour 

Table  12  displays  the  average  project  completion  times  under  this  scenario.  Table  13  compares 
percentage  utilization  of  resources  for  the  base  case  and  the  system  described  here,  and  Figure  23 
compares  cumulative  distributions  of  priority  1  new  products  project  completion  time  for  the  two 
scenarios.  Note  that  even  though  percentage  utilization  increases  at  most  by  2%,  the  increase  in 
cycle  time  is  quite  dramatic. 
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11     The  Importance  of  Priority  Coordination 

An  often-addressed  topic  in  the  product  development  literature  is  the  benefits  of  organizing  dif- 
ferent functions  under  one  manager  (we  call  this  a  "centralized"  system),  rather  than  letting 
them  operate  independently  under  different  managers  (which  we  call  a  "decentralized'"  system) 
(Wheelwright,  1989).  The  Plastics  division  operates  under  the  centralized  scenario:  Figure  I 
shows  that  all  functions  involved  in  product  development  activities  (e.g.,  product  development 
engineers,  product  management,  and  marketing)  are  grouped  under  one  manager.  Consequently, 
projects  are  assigned  the  same  priority  across  all  groups  — •  at  least,  in  principle.  Conversely,  if 
these  groups  were  placed  under  separate  managers,  projects  would  likely  face  different  priorities 
in  different  groups. 

To  examine  the  consequences  of  the  decentralized  organization,  we  analyzed  a  system  in 
which  manufacturing  engineers  and  product  management  treat  all  project-related  work  as  low 
priority  compared  to  their  support  activities.  Project  completion  times,  shown  in  Table  14,  are 
much  longer  for  the  decentralized  system.  Recall  that,  manufacturing  engineers  and  product 
management  play  relatively  small  roles  in  the  product  development  process  (see  Tables  3  and 
6),  in  terms  of  both  absolute  number  of  hours  contributed  and  percentage  of  time  dedicated 
to  project  related  work.  For  example,  only  10%  of  manufacturing  engmeers'  time,  and  12%  of 
product  management's  time,  is  spent  on  new  product  and  reformulation  projects.  Yet,  when  these 
groups  do  not  treat  project  work  as  first  priority,  project  completion  times  can  suffer  by  35%. 

12     Conclusion 

We  have  demonstrated  that  for  an  important  group  of  product  development  organizations  — 
namely,  those  that  pursue  multiple  concurrent  projects  using  shared  resources  —  process  models 
provide  a  promising  framework  for  better  understanding  and  managing  development  cycle  time. 
From  our  simulation  experiments,  we  are  able  to  draw  some  useful  insights  and  recommendations 
for  compressing  project  completion  times.  We  summarize  our  findings  below. 

Acknowledge  delays  thai  result  from  congestion  effects:  Development  cycle  times  experienced 
by  product  development  organizations  are  typically  longer  (and  often  much  longer)  than  estimates 
obtained  from  PERT  and  CPM  analyses.  The  delays  are  due  in  part  to  congestion  effects  that 
arise  from  2  sources:  (i)  the  inherent  uncertainty  in  the  product  development  environment,  and 
(ii)  the  contention  for  shared  resources  among  concurrent  projects.  Process  models  therefore  can 
play  an  important  role  in  the  management  of  product  development,  particularly  if  the  focus  is 
on  compressing  development  cycle  time,  -^nd  our  experience  suggests  that  such  models  can  be 
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created  and  maintained  without  much  difficulty  and  cost  (the  bulk  of  the  work  in  the  project  was 
in  identifying  and  collecting  data,  as  we  described  m  Adler  el  al.     1992b) 

Reduce  resource  utilizations:  An  obvious  method  for  compressing  development  cycle  time  is 
to  reduce  the  load  (i.e.,  percentage  utilizations)  of  the  resource  pools.  We  showed  how  to  use 
process  models  to  evaluate  resource  allocation  decisions,  to  identify  resources  that  are  likely  to 
be  bottlenecks,  and  to  quantify  the  benefits  of  an  additional  employee.  (For  example,  we  found 
that  adding  a  person  to  an  "uncritical"  resouce  may  have  virtually  no  impact  on  cycle  time.)  In  a 
similar  way,  process  models  can  identify  activities  that  are  most  suitable  for  process  improvement 

Control  new  project  starts:  Development  cycle  time  can  also  be  effectively  decreased  with 
better  management  of  new  project  starts.  We  considered  a  simple  policy  of  input  control  in 
which  new  projects  are  not  undertaken  whenever  the  number  of  ongoing  projects  in  the  division 
exceeds  a  preset  cutoff  level.  Our  simulation  experiments  showed  that  this  input  control  policy 
can  greatly  improve  project  completion  time,  and  that  simulation  is  a  useful  tool  for  determining 
the  "optimal"  cutoff  level.  Our  results  suggested  that  even  greater  gains  can  be  realized  by 
implementing  a  "pull"  policy  in  which  project  starts  are  triggered  by  project  completions.  Here, 
we  trade  off  the  value  of  undertaking  more  projects  with  the  benefit  of  completing  each  project 
in  a  more  timely  manner. 

Balance  workload  among  resources:  A  third  method  for  improving  cycle-time  performance  is  to 
balance  the  workload  among  resources.  This  can  be  achieved  through  cross-training  which  allows 
resources  to  reallocate  portions  of  their  work  to  less  heavily  utilized  resources  in  critical  periods. 
We  found  that  the  benefits  of  cross-training  and  work-pooling  decreases  as  the  workload  between 
resources  become  more  equal.  We  also  noted  that  reassigning  work  to  a  secondary  resource  may  in 
general  result  in  longer  processing  times  and  greater  likelihoods  of  errors.  In  light  of  our  findings 
regarding  the  incremental  benefits  of  work-pooling,  it  follows  that  there  is  an  "optimal"  level  of 
cross-training,  and  that  one  can  use  process  models  to  determine  that  level. 

Coordinate  priorities  between  resources:  Our  model  suggests  that  a  "centralized"  system  of 
management,  in  which  the  different  product  development  functions  all  operate  under  one  manager, 
can  be  much  more  effective  than  a  "decentralized"  organization,  in  which  different  functions  report 
independently  to  different  managers,  at  least  in  terms  of  cycle-time  performance.  Even  a  resource 
pool  that  contributes  only  marginally  to  the  product  development  process  can  significantly  delay 
project  comnpletion  by  assigning  it  low  priority. 

Finally,  we  used  our  simulation  models  to  investigate  some  interesting  and  diflRcult  issues. 
First,  we  explored  the  impact  of  using  a  first-in-first-out  service  discipline  rather  than  a  round- 
robin  convention.  Although  our  preliminary  results  in  this  study  are  inconclusive,  they  do  raise  the 
question  of  when  is  one  discipline  better  than  another'^'  Is  the  answer  dependent  on  the  structure 
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of  the  network  or  the  characteristics  of  processing  times'^  Does  the  existence  of  additional  "mental 
set-up"  time  imply  that  first-in-first-out  is  always  preferable';' 

Second,  we  investigated  how  different  iteration  structures  can  aiTect  overall  cycle  time.  Our 
results  suggest  that  if  the  total  amount  of  time  mvolved  is  kept  constant,  project  completion  time 
is  not  significantly  affected  by  an  increase  in  the  probability  that  activities  have  to  be  repeated.  In 
these  experiments,  we  were  interested  in  the  question  of  time  allocation:  Is  it  more  advantageous 
to  allocate  additional  time  to  each  protyping  run  if  the  additional  time  investment  resulted  in  a 
greater  likelihood  that  the  prototype  is  acceptable;  or  is  it  better  to  perform  several  iterations  of 
prototypes,  each  taking  a  smaller  amount  of  time?  Is  it  better  to  allocate  the  additional  effort 
towards  the  end  of  the  process  (e.g.,  m  manufacturing  scale-up)  or  at  the  beginning  (during 
prototype  runs)? 

It  is  clear  that  these  are  two  important  topics  in  product  development  that  remain  largely 
unresolved.  We  believe  that  the  framework  we  have  suggested,  namely,  representating  product 
development  as  a  stochastic  processing  network,  provides  a  powerful  tool  for  exploring  such  is- 
sues. We  plan  to  undertake  some  of  these  tasks  in  future  work  and  hope  that  others  also  find 
this  direction  of  research  appealing.  We  close  by  noting  that  our  model  is  a  highly  aggregated 
representation  of  the  product  development  activities  in  the  Plastics  division.  We  believe  that 
much  can  be  gained  from  analyzing  various  components  in  greater  detail. 
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Resource  Name 

Number  of 
servers 

Maximum  Server  Capacity 
(hrs/week/server  ) 

PD  Engineer 

6 

60 

PD  Technician 

9 

55 

Manufacturing  Engineer 

5 

45 

Application  Engineer 

4 

60 

Technical  Services 

6 

55 

Product  Management 

4 

45 

Specifications 

1 

45 

Table  1:  Resource  Characteristics 


New  Products 

Reformulations 

Priority  1 

3.00 

1.00 

Priority  2 

2.50 

1.00 

Table  2:  Rates  of  New  Project  Starts  (Projects/Year) 


Activity  Name 

Activity  Description 

Phase  1 

Identify  customer  expectations  and  project  concepts; 
explore  technical,  manufacturing,  and  market  feasibility 

Phase  2 

Form  project  team;  develop  technical  and 

p 

h 
a 
s 
e 

3 

Prototyping* 

Create  samples  and  test  for  conformance  to  materials 
and  product  requiremnts 

Marketing 

Determine  competitiveness  of  product,  establish  market 
position,  formulate  sales  strategy,  identify  lead-customer 

Mfg  Scale-Up* 

Make  product  prototype  in  plant  to  uncover  any  manufacturing 
issues,  test  for  conformance  to  product  requirements 

Specs 

Determine  whether  product  is  subject  to  government  regulations 

Qual  Testing 

Test  product  for  conformance  to  all  specifications 

Phase  4* 

Complete  customer  trials,  manufacturing  scale-ups,  product 
documentation;  launch  product 

*  Activities  in  reformulation  projects 

Table  3:  Activity  Descriptions 


PD 
Engr 

PD 
Tech 

Mfg 

Engr 

Appl 
Engr 

Tech 
Svcs 

Prod 
Mgt 

Specs 

New  Product  Projects 

Phase  1 

66 

135 

Phase  2 

104 

82 

Proto 

102 

90 

7 

11 

Mkt 

76 

84 

Mfg  Scale- Up 

58 

27 

101 

Specs 

26 

Quals 

125 

125 

1050 

Phase  4 

850 

179 

240 

285 

220 

Reformulation  Projects 

Proto 

414 

412 

60 

60 

Mfg  Scale-Up 

30 

160 

Phase  4 

115 

45 

84 

129 

67 

Table  4:  Processing  Times 


PD 

Engr 

PD 

Tech 

Mfg 
Engr 

Appl 
Engr 

Tech 
Svcs 

Prod 
Mgt 

Specs 

Support 

0.67 

0.73 

44.44 

20.00 

21.82 

40.00 

40.00 

Admin 

20.00 

21.82 

26.67 

12.67 

23.27 

26.67 

26.67 

Table  5:  Fraction  of  Time  Devoted  to  Administrative  and  Support  Activities 


._.    .  . 

PD 

Engr 

PD 

Tech 

Mfg 
Engr 

Appi 
Engr 

Tech 

Svcs 

Prod 
Mgt 

Specs 

Priority  1  Work 

New  Prod 

39.82 

16.56 

8.29 

1935 

19.09 

10  13 

8.67 

Reform 

3.21 

2.02 

1.69 

1.72 

1.06 

0.00 

3  25 

Support 

0.67 

0.73 

44.44 

20.00 

21.82 

40.00 

40.00 

Admin 

20.00 

21.82 

26.67 

12.67 

23.27 

26.67 

26.67 

SUBTOTAL  Priority  1 

63.69 

41.12 

81.10 

53.73 

65.24 

76.79 

75.88 

Priority  2  Work 

New  Prod 

33  18 

13.80 

6.91 

16.13 

15.91 

8.45 

7.22 

Reform 

2.67 

1.67 

1.40 

1.43 

0.88 

0.00 

2.71 

SUBTOTAL  Priority  2 

35.85 

15.47 

831 

17.56 

16.79 

8.45 

9.93 

TOTAL 

99.54 

56.59 

89.41 

71.29 

82.03 

85.24 

88.51 

Table  6:  Percent  Utilization  Factors 


Simulated 
Average 

90th 
Percentile 

Actual 
Average 

PERT 

Prediction 

Actual-to-PERT 
Ratio 

SOJOURN  TIME 
New  Products 

Priority  1 

84  weeks 

130  weeks 

82  weeks 

76  weeks 

1,08 

Priority  2 

200  weeks 

350  weeks 

>  3  years 

76  weeks 

>  1.97 

Reformulations 

Priority  1 

21  weeks 

32  weeks 

6-9  months 

16  weeks 

1.50-2,25 

Priority  2 

55  weeks 

90  weeks 

1-3  years 

16  weeks 

3.13-9.38 

NUMBER  OF  CONCURRENT  PROJECTS 

New  Products 

Priority  1 

5 

8 

6 

- 

- 

Priority  2 

10 

16 

8 

- 

- 

Reformulations 

Priority  1 

<  1 

1 

1 

- 

- 

Priority  2 

1 

2 

3 

- 

- 

Table  7:  Simulation  Results 


PD  Engr 

PD  Tech 

Appl  Engr 

Tech  Svcs 

0.65 

0.11 

0.35 

.46 

Table  8:  Fraction  of  Time  Spent  m  Overtime 


Case 

Added  Resource  in 

New  P 

roduc 

ts 

Reformulations 

Priority  1 

Priority  2 

Priority  I 

Priority  2 

Base 

— 

84 

200 

21 

55 

1 

Appi  Engr  (3%)+ 

84 

0% 

207 

-4% 

21 

0% 

58     -5% 

2 

Tech  Svcs  (3%) 

82 

2% 

185 

8% 

20 

5% 

50     9% 

3 

PD  Engr  (3%) 

81 

4% 

150 

25% 

20 

5% 

43     22% 

4 

1  in  Each  (9%) 

80 

5% 

141 

30% 

20 

5% 

41      25% 

■*■  Percent  increase  in  total  resource  pool 

*  Percent  improvement  in  project  completion  time 

Table  9:  Effect  on  Average  Project  Completion  Times  of  Adding  Resources 


Number  of 
Concurrent  Projects 

Average  Cycle  Time 

Priority  1  New  Product 
Projects  Completed  per 
Year  (Throughput  Rate) 

New  Products 

Reformulations 

Priority  1 

Priority  2 

Priority  1 

Priority  2 

Open  System 

84 

200 

21 

55 

3.0 

5 

82  (2%) 

173(14%) 

20  (5%) 

47(15%) 

3.1  (-2%)+ 

3 

78  (7%) 

114  (43%) 

20  (5%) 

30  (45%) 

1.8(41%) 

1 

77  (8%) 

94  (53%) 

19  (10%) 

24  (56%) 

0  7  (78%) 

*  Percent  improvement  in  project  completion  time 

"•■  Percent  decrease  in  number  of  priority  1  new  product  projects  completed  per  year 

Table  10:  Project  Completion  Times  and  Throughput  Rates  -  Pull  System 


Service 
Discipline 

New  Products 

Reformulations 

Priority  1 

Priority  2 

Priority  1 

Priority  2 

Round-Robin 

84 

200 

21 

55 

FIFO 

84  (0%)* 

202  (1%) 

21  (5%) 

59  (7%) 

*  Percent  improvement  in  project  completion  time 
Table  11:  Project  Completion  Times  with  FIFO  Service  Discipline 


System 

New  Products 

Reformulations 

Priority  1 

Priority  2 

Priority  1 

Priority  2 

Base  Case 

84 

200 

21 

55 

Iterations  with 
Inefficiencies 

96  (14%) 

320  (60%) 

20  (-5%) 

52  (-5%) 

*  Percent  improvement  in  project  completion  time 
Table  12:  Average  Project  Completion  Times  -  Iterations  with  Inefficiencies 


PD 

Engr 

PD 

Tech 

Mfg 
Engr 

Appl 
Engr 

Tech 
Svcs 

Prod 

Mgt 

Specs 

Base  Case 

88.19 

63.92 

89.25 

71.34 

82.16 

86.75 

82.47 

Iterations  with 
Inefficiencies 

88.35 

64.63 

90.98 

73.17 

81.11 

86.67 

81,82 

Table  13:  Utilization  Profile  -  Inefficiencies  in  Cycling 


System 

New  Products 

Reformulations 

Priority  1 

Priority  2 

Priority  1 

Priority  2 

Centralized 

84 

200 

21 

55 

Decentralized 

95 

190 

24 

53 

Table  14:  Project  Completion  Times  with  Lack  of  Priority  Coordination 
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Figure  1:  Organization  Chart  of  the  Chemicals  Inc. 


Figure  2:  Activities  Flow  Diagram  -  New  Products 
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Figure  3:  Activities  Flow  Diagram  -  Reformulations 
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